Reindexação Automática em SGBDs Relacionais

We propose a solution to the automatic and online reindex problem. The proposed mechanism runs continuously and with almost no human intervention. The adopted strategy is based on ad-hoc heuristics that monitor the index fragmentation level and, when necessary, reindex it automatically. We have actually implemented our ideas within the PostgreSQL DBMS code. Practical performance tests show the effectiveness of our approach. Resumo. Neste trabalho, propõe-se uma solução para o problema da reconstrução automática e online de índices. O mecanismo proposto executa de forma contínua e praticamente sem intervenção humana. A estratégia adotada baseia-se em heurísticas ad-hoc que monitoram o nível de fragmentação das estruturas de índice e, sempre que necessário, as reconstroem automaticamente. Nossas idéias estão implementadas no SGBD PostgreSQL. Testes de desempenho são apresentados para mostrar a aplicabilidade da nossa abordagem na prática. 1. Introdução As aplicações de bancos de dados têm se tornado cada vez mais complexas e variadas. Estas podem ser caracterizadas por manipularem grandes volumes de dados e pela demanda por baixo tempo de resposta das consultas e por alta produtividade (throughput) das transações. Neste contexto, a sintonia (tuning) [Shasha e Bonnet 2003] das estruturas de índice tem se revelado ainda mais importante, influindo diretamente no desempenho dos sistemas de bancos de dados. Realizar o ajuste das estruturas de índice nas aplicações atuais tem se tornado uma tarefa extremamente complicada para os administradores de bancos de dados (DBAs). Esta tarefa requer um profundo conhecimento acerca dos detalhes de implementação dos sistemas de gerenciamento de bancos de dados (SGBDs), das características dos dados armazenados, das aplicações e da carga de trabalho (conjunto de consultas e atualizações) submetida ao SGBD [Bruno e Chaudhuri 2007a], [Luhring et al 2007]. Os principais fabricantes de SGBDs oferecem ferramentas para prover suporte à sintonia automática (ou auto-sintonia) de índices (Ex.: [Zílio et al 2004], [Bruno e Chaudhuri 2005]). A idéia é auxiliar os DBAs através da análise automática da carga de trabalho e, com base nesta análise, recomendar a criação ou remoção de índices. Entretanto, tais ferramentas adotam uma abordagem estática (offline) na solução do problema e transferem para o DBA tarefas de sintonia importantes e decisões relativas à quando modificar o esquema e quais de fato são as modificações necessárias. Além disso, são soluções ad-hoc e que exigem participação de DBAs especialistas. Algumas iniciativas recentes apresentam descrições de protótipos que implementam algumas funcionalidades na direção da sintonia automática e contínua das estruturas de índice [Schnaitter et al 2006], [Luhring et al 2007], [Costa 2005], [Salles e Lifschitz 2005], [Lifschitz e Morelli 2006]. Alguns desses trabalhos procuram estender o SGBD PostgreSQL adicionando funcionalidades de auto-sintonia (Ex.:. [Salles 2004], [Costa 2005], [Salles e Lifschitz 2005], [Lifschitz e Morelli 2006], [Luhring et al 2007]). Os fabricantes de SGBDs comerciais, tais como: DB2, Oracle e SQL Server, também têm procurado investigar novas funcionalidades que possibilitam a manutenção automática das estruturas de índice [Bruno e Chaudhuri 2007a]. Contudo, ainda há muito desconhecimento sobre o momento ideal de criar ou remover um determinado índice e, principalmente, de quando recriá-lo. O benefício trazido pela existência de um determinado índice, para uma determinada consulta, é influenciado por dois fatores: a sua seletividade da consulta e o grau de fragmentação do índice. Logo, manter índices fragmentados pode degradar o desempenho da carga de trabalho submetida ao SGBD. Por outro lado, a remoção de um índice fragmentado para sua posterior criação pode gerar um overhead desnecessário [Shasha e Bonnet 2003]. Este trabalho apresenta um mecanismo que possibilita automatizar a recriação de índices fragmentados e analisa em detalhes uma heurística para tal automação. A abordagem proposta executa independentemente de interações com os DBAs. Especificamente, desenvolvemos um conjunto de heurísticas que executam continuamente, detectam a existência de índices fragmentados, e, sempre que necessário, reconstroem estes índices, evitando assim os malefícios causados pela existência de índices fragmentados. A arquitetura concebida neste trabalho foi implementada em um SGBD de código aberto, o PostgreSQL [Postgresql 2009]. Esta implementação teve a sua eficácia comprovada através dos testes que foram realizados. O restante deste artigo está organizado da seguinte maneira: A seção 2 apresenta os trabalhos relacionados. A seção 3 discute o estudo realizado sobre a fragmentação de índices e os resultados dos testes executados que comprovam a necessidade da preocupação com índices fragmentados. Na seção 4 descreve uma proposta de solução para o problema da reconstrução automática de índices. Por fim, a seção 5 conclui este trabalho e aponta direções para futuras pesquisas. 2. Trabalhos Relacionados No contexto da sintonia de índices, foram identificados alguns trabalhos relacionados que se propõe a realizar a sintonia automática de índices em SGBDs, buscando melhorar o desempenho das execuções de consulta através de sugestões de criação ou remoção de índices. Em [Sattler et al 2003], [Sattler et al 2004] propõe-se um middleware, situado entre as aplicações e o SGBD DB2, que sugere, de forma automática, a criação de índices. Esta solução baseia-se em comandos proprietários do DB2 (Ex.: SET CURRENT EXPLAIN MODE RECOMMEND INDEXES), os quais não existem em outros SGBDs. Além disso, exige-se que todas as cláusulas SQL sejam enviadas para o middleware e não mais para o SGBD, o que implica na necessidade de re-escrever as aplicações previamente existentes e na impossibilidade de se gerenciar uma carga de trabalho que seja submetida diretamente ao SGBD. Os trabalhos propostos em [Salles 2004], [Salles e Lifschitz 2005], [Costa 2005] apresentam um componente de auto-sintonia implementado junto ao código do PostgreSQL, que possibilita a criação automática de índices. Utilizou-se para tanto configurações de índices hipotéticos, índices existentes apenas na metabase, que podem ser considerados para construção de planos de consulta alternativos. Em [Schnaitter et al 2006] os autores apresentam um protótipo de um framework de auto-sintonia denominado COLT (Continuos On-Line Tuning), o qual monitora as consultas submetidas ao SGBD e ajusta de forma automática a configuração de índices, levando em consideração a restrição do espaço disponível para estas estruturas. O COLT foi implementado de forma integrada ao PostgreSQL. Em [Luhring et al 2007] os autores apresentam uma abordagem para a sintonia automática de índices que se baseia na utilização de índices hipotéticos e independe de qualquer interação do DBA. Esta abordagem também foi implementada junto ao código do PostgreSQL. Em [Bruno e Chaudhuri 2007a], [Bruno e Chaudhuri 2007b] os autores apresentam uma ferramenta de sintonia automática de índices implementada como uma extensão do Microsoft SQL Server 2005. Este novo componente executa continuamente e, reagindo a variações na carga de trabalho ou nas características dos dados, modifica de forma automática o projeto físico do banco de dados. Os algoritmos propostos apresentam baixa sobrecarga e levam em consideração restrições no espaço de armazenamento, o custo da atualização das estruturas de índices causadas pelas operações de update e o custo de criar estruturas físicas temporárias. Contudo, todos estes trabalhos não consideram a possível recriação automática de índices fragmentados. Assim, a abordagem proposta neste artigo estende os trabalhos anteriores realizando não somente a criação e a remoção, mas também a reconstrução (reindex) automática de índices. Como os índices considerados neste trabalho obedecem a organizações em árvore B + (os ponteiros de dados encontram-se armazenados somente nos nós folhas da árvore) um grande número de inserções, atualizações ou eliminações de chaves, fatalmente provocará o particionamento de páginas de disco (page splits [Shasha e Bonnet 2003]). Este fato pode causar fragmentação na estrutura, dependendo da localização de onde venham a ser alocadas novas páginas. A Figura 1 apresenta um índice que não sofreu nenhum particionamento de páginas de disco; enquanto que a Figura 2 exibe o mesmo índice após muitas atualizações. Figura 1. Índice não fragmentado. Figura 2. Índice fragmentado As setas apresentadas nas Figuras 1 e 2 revelam a ordem na qual o índice será percorrido. Deve-se perceber a ausência de múltiplos deslocamentos a posições anteriores em um índice apresentando grau de fragmentação zero. Já um índice fragmentado prejudica as operações de varredura, já que o artefato físico responsável pela leitura pode ser obrigado a realizar muitos deslocamentos físicos. É importante lembrar que a preocupação com a fragmentação está relacionada à varredura do índice e não aos acessos individuais as páginas em disco. Uma solução imediata para esse problema é a completa reconstrução periódica de todos os índices, de preferência em instantes de pouca atividade. Entretanto, tal abordagem traria dois graves inconvenientes: 1) Os grandes bancos de dados podem possuir centenas ou mesmo milhares de índices; Reconstruir todos, por mais “quieto” que esteja o Sistema, causaria um esforço computacional considerável; 2) Há índices cujas tabelas não sofrem atualizações ou são raramente atualizadas. Nestes casos, a reconstrução não traz benefício algum. Este trabalho apresenta argumentos que atestam a necessidade da recriação periódica de índices fragmentados, para que o desempenho no processamento de consultas sobre as tabelas nas quais foram criados não seja prejudicado. Além disso, propõe-se uma abordagem para a identificação e reconstrução automáticas de índices fragmentados. 3. Estudo da Fragmentação de Índices A existência de um índice fragmentado prejudica a execução de consultas que realizam varreduras (ordenação, agrupamento, filtros como intervalos) e apresentam alta seletividade (conjunto de linhas retornadas). Durante a realização dos testes práticos que levaram à confecção deste trabalho, observou-se que o otimizador somente utiliza um índice se a seletividade da consulta estiver abaixo de um determinado valor limítrofe. Um índice fragmentado implica em maior consumo de espaço físico e maior duração na execução de consultas com varreduras, pois quanto maior a duração de execução das consultas com baixa velocidade no acesso (E/S) aos dados, maior será o consumo de recursos, aumentando assim o custo de processamento da consulta. Para comprovar estes fatos, realizou-se o seguinte experimento: a partir de uma tabela escolhida aleatoriamente e um determinado índice a ela associado, elaborou-se uma rotina de carga (com inserções, remoções e atualizações) que resultava na fragmentação deste índice. Em seguida, estando a tabela preenchida, comparou-se o tempo de execução de uma consulta antes e depois da reconstrução do índice. Os dados coletados mostram que a reconstrução permite melhoras pontuais em dois aspectos: duração/custo da consulta e o espaço ocupado pelo índice. A seguir, discutimos em detalhes o experimento realizado. Considere a tabela Venda, cujo esquema é descrito na Figura 3, inicialmente carregada com 400.000 tuplas. Elaborou-se uma rotina de carga de uma segunda tabela denominada Venda2, a qual possui a mesma estrutura da tabela Venda, com o seguinte roteiro: